Themes     
  • plain HTML
  • Light Mode
    •

    Pretty Bad Privacy

     This article is in early drafting process, made public so I get comments and more people can be aware
    OpenPGP
    Pretty Good Privacy standard, derives from the original PGP implementation. "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation. The term "OpenPGP" refers to the protocol described in this and related documents.
    GnuPG / GPG
    Gnu Privacy Guard, main/only implementation of OpenPGP

    OpenPGP standard

    Compression

       Furthermore, compression has the added side effect that some types of
   attacks can be thwarted by the fact that slightly altered, compressed
   data rarely uncompresses without severe errors.  This is hardly
   rigorous, but it is operationally useful.  These attacks can be
   rigorously prevented by implementing and using Modification Detection
    RFC4880, November 2007

    Not sure about this one, I’ll go check but this cause few issues in SSH and TLS, so I wouldn’t be surprised that it was also the case for OpenPGP.

    Ciphers

    The OpenPGP standard mandates that some ciphers must be present in the implementation, they are broken and well known to be.

    9.1.  Public-Key Algorithms

ID           Algorithm
--           ---------
1          - RSA (Encrypt or Sign) [HAC]
2          - RSA Encrypt-Only [HAC]
3          - RSA Sign-Only [HAC]
16         - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
17         - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18         - Reserved for Elliptic Curve
19         - Reserved for ECDSA
20         - Reserved (formerly Elgamal Encrypt or Sign)
21         - Reserved for Diffie-Hellman (X9.42,
             as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm

Implementations MUST implement DSA for signatures, and Elgamal for
encryption. […]
9.2.  Symmetric-Key Algorithms

ID           Algorithm
--           ---------
0          - Plaintext or unencrypted data
1          - IDEA [IDEA]
2          - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
             168 bit key derived from 192)
3          - CAST5 (128 bit key, as per [RFC2144])
4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5          - Reserved
6          - Reserved
7          - AES with 128-bit key [AES]
8          - AES with 192-bit key
9          - AES with 256-bit key
10         - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm

Implementations MUST implement TripleDES. […]
9.4.  Hash Algorithms

ID           Algorithm                             Text Name
--           ---------                             ---------
1          - MD5 [HAC]                             "MD5"
2          - SHA-1 [FIPS180]                       "SHA1"
3          - RIPE-MD/160 [HAC]                     "RIPEMD160"
4          - Reserved
5          - Reserved
6          - Reserved
7          - Reserved
8          - SHA256 [FIPS180]                      "SHA256"
9          - SHA384 [FIPS180]                      "SHA384"
10         - SHA512 [FIPS180]                      "SHA512"
11         - SHA224 [FIPS180]                      "SHA224"
100 to 110 - Private/Experimental algorithm

Implementations MUST implement SHA-1.  Implementations MAY implement
other algorithms.  MD5 is deprecated.
    RFC4880, November 2007

    Some additionnal ciphers got added later on, but this basically mean that you cannot be sure that a OpenPGP message you sent wasn’t done in more-or-less plaintext. DES was broken by the EFF in 199x, 3DES is basically now on about the same size (NIST: 80 bits of security) but computing power got much better, SHA1 was probably still known as okay but could be better (as SHA2 was already a thing), DSA was probably not now enough as good to be hardcoded, no idea for Elgamal.

    I tried few years ago to build a GnuPG without support for theses broken ciphers, and I failed doing so. One can note that SSH requires 3DES-CBC, but it can be disabled or non-implemented (tinyssh).

    13.4.  Plaintext

   Algorithm 0, "plaintext", may only be used to denote secret keys that
   are stored in the clear.  Implementations MUST NOT use plaintext in
   Symmetrically Encrypted Data packets; they must use Literal Data
   packets to encode unencrypted or literal data.
    RFC4880, November 2007

    I guess this one is related to SigSpoof

    14.  Security Considerations

   * As with any technology involving cryptography, you should check the
     current literature to determine if any algorithms used here have
     been found to be vulnerable to attack.
[…]
   * There is a somewhat-related potential security problem in
     signatures.  If an attacker can find a message that hashes to the
     same hash with a different algorithm, a bogus signature structure
     can be constructed that evaluates correctly.

     For example, suppose Alice DSA signs message M using hash algorithm
     H.  Suppose that Mallet finds a message M' that has the same hash
     value as M with H'.  Mallet can then construct a signature block
     that verifies as Alice's signature of M' with H'.  However, this
     would also constitute a weakness in either H or H' or both.  Should
     this ever occur, a revision will have to be made to this document
    RFC4880, November 2007 
    
$ gpg --version
gpg (GnuPG) 2.2.10
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/haelwenn/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

    “LOL”

    It leaks a pile of metadata (time, implementation name+version, …)

    There is no deniability possible, there is quite a difference between no-authentication and deniability, to be elaborated on

    Your public key/identity will end up on the keyservers at some point, no exception.

    There is no forward secrecy

    OpenPGP in real life

    Real Name policy and other stuff that should be optionnal in the Public Key Verification process (An ID card? Seriously?).

    The keyservers/Web-of-Trust is architecturaly vunerable to a DoS by spam. keyservers.md

    Bonus: Keybase is a fuck

    Keybase is what you get when you want crypto (just the math), but you do not care about security (they are called secrets for a reason) or privacy (social-media with a cryptographically verified graph that lives forever…).

    As an alternative (and if you still want OpenPGP), I think putting your fingerprint everywhere you can and putting you minimal public key on your blog is a much better way, and it can be automatised a bit (OPENPGPKEY DNS record, IndieWeb rel="openpgp", …).

    See also

    References